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DESCRIPTION 

CLUSTERED NETWORKED DEVICES 

5 The present invention relates to networked systems composed of a 

plurality of devices clustered for the exchange of data and control messages 
formatted according to predetermined protocols and, in particular although not 
essentially, to such systems where inter-device communication between some 
of the devices is via wireless link. The invention further relates to devices for 
10 use in groups or clusters to form such systems. 

Networked interconnection of devices has long been known and used, 
starting from basic systems where different system functions have been 
provided by separate units, for example hi-fi systems or security systems 

15 having detectors, a control panel and one or more alarm sounders. A 
development has been the so-called home bus systems where a greater 
variety of products have been linked with a view to providing enhanced overall 
functionality in for example domestic audio/video apparatus coupled with a 
home security system and the use of telephone. An example of such a home 

20 bus system is the domestic digital bus (D2B), the communications protocols 
for which have been issued as standard I EC 1030 by the International 
Electrotechnical Commission in Geneva, Switzerland. The D2B system 
provides a single wire control bus to which all devices are interfaced with 
messages carried between the various devices of the system in a 

25 standardised form of data packet. 

With all such domestic equipment interconnection schemes, there is a 
problem of connection to apparatus not supporting the communications 
protocols of the scheme. As an example, a user may have a music system 
comprising interconnected units such as a compact disc (CD) player, amplifier, 

30 tuner and cassette player which communicate with each other using a first set of 
communications protocols, together with an audio visual system comprising for 
example a television, video recorder and satellite receiver which communicate 
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using a second set of protocols. In the absence of a certain degree of 
compatibility with existing systems, a user may be faced with having to replace 
many items at one time. One way to reduce this problem is to provide a 
gateway device which supports two or more sets of communications protocols 
5 and can "translate" messages between them, as described in US Patent 
5,754,548 (Hoekstra et al), where D2B is used as a subsystem within a home 
electronic bus (HEB) system. 

As is also described in US 5,754,548, such gateway devices can be used 
as part of a link between two clusters of bus-connected devices supporting the 
10 same communications protocols, but with different protocols governing 
communications on the link between the clusters. The link between the clusters 
may, for example, comprise a wireless (infra-red or RF) channel between the 
two gateway devices, whilst the cluster devices themselves are hard wired to 
respective serial data buses. 

15 

It is an object of the present invention to provide a networked system of 
devices including one or more communications links capable of handling 
digital data. 

In accordance with a first aspect of the present invention there is 
20 provided a local communication system comprising: 

a first cluster of devices interconnected for the communication of 
messages via a first data bus and in accordance with a first set of 
communication protocols; 

a second cluster of devices interconnected for the communication of 
25 messages via a second data bus and in accordance with said first set of 
communication protocols; and 

a data channel linking a device of said first cluster and a device of said 
second cluster, said data channel supporting communication of messages in 
accordance with a second set of communications protocols; 
30 wherein a device of the first cluster holds a stored software 

representation of operational features of a selected device of the second cluster 
and any device of the first cluster wishing to interact with said selected device 
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instead interacts with said stored representation. As will be described 
hereinafter, interaction with a locally held proxy avoids the need for rewriting of 
cluster communications protocols simply to accommodate different transport 
capabilities and/or conditions on the bridge. 
5 The stored representation may be generated by the said selected device 

and transmitted via said data channel to said device of the first cluster, and the 
said stored representation may be modified in response to limitations of said 
data channel, in which case the modification may occur on receipt by said 
device of the first cluster, in response to limitations of said data channel. 

10 The stored representation may model the said selected device as if it 

were a device of the first cluster, and the said device of the first cluster holding 
the stored representation may suitably be that device of the first cluster to which 
the data channel is connected. The said data channel may be a wireless link. 
In accordance with a further aspect of the present invention, there is 

1 5 provided a communications device having the technical features of a cluster- 
connected device in a system as recited above. 

Further features and advantages of the present invention will become 
apparent from reading of the description of preferred embodiments of the 
20 invention, given by way of example only and with reference to the 
accompanying drawings, in which: 

Figure 1 represents an arrangement of devices forming three linked 
clusters; 

Figure 2 shows a pair of clusters using a different interconnect 
25 mechanism to the arrangement of Figure 1 ; 

Figure 3 shows three clusters using a still further interconnect 
mechanism different to the arrangements of either Figure 1 or Figure 2; and 

Figure 4 schematically represents an arrangement for the handling of 
timing issues over the bridge in any of Figures 1 to 3. 

30 

A first arra^ devices is shown in Figure 1 , wffh 

the devices being divided into three clusters 10, 20, 30, each based around a 
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respective bus 18, 28, 38 supporting communication in accordance with IEEE 
Standard 1394 connect and communications protocols. In the following 
examples, reference is made to various communications protocols including 
IEEE 1394, IEEE 802.11, and HAVi (the Home Audio/Video interoperability 
5 standard based around 1394), and the disclosure of the specification of these 
various protocols is incorporated herein by reference. As will be recognised by 
the skilled reader, however, conformance with such protocols is not essential 
to the operation of the present invention. 

The devices in the first cluster 10 comprise a set-top box (STB) 11, a 

10 first digital video recorder (DVHS-1) 12, a digital versatile disc (DVD) player 13 
and an RF send and receive unit 19 which acts as a gateway device for the 
first cluster. The devices in the second cluster 20 comprise a first television set 
(TV-1) 21, a second digital video recorder (DVHS-2) 22 and an RF send and 
receive unit 29 which acts as a gateway device for the second cluster. The 

15 devices in the third cluster 30 comprise a second television set (TV-2) 31, a 
third digital video recorder (DVHS-3) 32, and an RF send and receive unit 39 
which acts as a gateway device for the third cluster. 

The second and third clusters 20, 30 communicate with the first 10 via 
respective RF links 41, 42 between the gateway devices at data rates which 

20 may be up to 8Mbit/sec or even higher. At these rates, digital video 
transmitted from one cluster to another may be compressed according to the 
known MPEG standards. HAVi commands may also be exchanged between 
the clusters as indicated by arrows 17, 27, 37: note that the channel for these 
commands may be integrated with the RF channel or it may be separate. 

25 In the system of Figure 1, the main value of the cordless link is for 

presentation, namely getting content from a source (such as the STB 1 1 in the 
first cluster) to the point of consumption (e.g. the TV-1 in the second cluster). 
This is particularly relevant where the source is tethered to a delivery medium, 
such as cable, terrestrial/satellite antenna, phone line, etc. From a logical point 

30 of view, the gateways and RF links may be treated as a single device 40 (as 
indicated by the dashed outline) such that the system as a whole then 
comprises just 1394-linked devices, although different timing issues on either 
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side of the bridge "device" 40 will need to be addressed, as will be described 
in further detail below. 

A handheld PIA-like unit may be used for TV viewing although this is 
not necessarily of value since most rooms will have a TV anyway. PIA units 
5 have compelling value for Internet Surfing and home control, however, and 
they also are useful for supporting interactive TV (e.g. background information 
to advertisements, TV shows, etc.). 

For true mobility within the home, (e.g. using a PIA-type unit) the TV 
picture should be stable when stationary; however, when moving some flutter 
10 is probably acceptable, and this is achievable using the high frequency RF link 
and MPEG compression. 

In such systems, related issues include the need to protect the cordless 
signal from casual eavesdropping, particularly for pay-per-view content; a 
need to support interactive services (e.g. based on Java, MHEG); and a need 
15 to retain synchronisation between audio and video - for example, if these 
components are sent via separate routes. 

In connection with access to the MPEG stream, some STB designs 
may decode right down to YC / CVBS / RGB allowing no access to the MPEG 
stream itself, whilst support for 1394/HAVi presumes that products are 
20 1394/HAVi equipped which may not always be the case. 

Considering the RF related issues, and beginning with those relating to 
MPEG streaming, for correct timing of audio and video, the MPEG 90kHz 
reference clock needs to be conveyed to the receiver via the RF channel. In 
order to broadcast to several receivers, there is no problem if all the receivers 
25 are on the same 1394 bus (i.e. in the same cluster) but where there are 
several clusters, it is recommended to use a dedicated MPEG stream to each, 
although the gateway device for the cluster sending out the MPEG streams 
(the source 1394 cordless AV adapter node CAVa) has to be able to configure 
this streaming. 

30 In terms of presentation issues, to protect against possible errors 

caused by the radio channel, duplicate MPEG streams may be sent. To 
protect against possible delay caused by the radio channel the content could 
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be 'pushed' at a "faster than realtime" rate to temporary storage at the receive 
side. It is noted that DVD has the unique issue of high bandwidth graphic 
overlay which demands massive radio bandwidth for real-time transfer - this 
issue is beyond the scope of the present application, however. 
5 In terms of recording or archiving, the streaming may be given a lower 

priority for the radio bandwidth, assuming sufficient 'spooling' storage is 
available on the sending side of the link (this helps with bandwidth 
management). To ensure a robust result, improved error protection may also 
be used (e.g. full acknowledged packet transfer). 

10 Products will not generally be isolated - they will be part of a wired 1394 

cluster (even if only consisting of 2 products/devices); however, the basic 
requirement of presentation is to communicate from one product to another, 
either within the same 1394 cluster, or between clusters. It is not a necessary 
requirement that clusters need to communicate one to another at the 1394 

15 level. 

In terms of alternative solutions to the problems of interconnection, 
Figure 1 represents a cordless MPEG link approach. Assuming presentation is 
the major requirement; this could imply simple one directional MPEG 
streaming from source to sink (left to right, or right to left, in the Figure). The 

20 approach keeps the 1394 buses (clusters) entirely separate, that is to say 
without requiring communications over the RF link to be 1394 compliant. The 
receive side must have the ability to control the signal originating devices 
(sources) within the 1394 cluster on the send side. 

The gateway (1394 CAVa) is a special HAVi Full AV controller (FAV) 

25 device. The 1394 CAVa hosts Device Control Modules (DCM's) of devices 
located on remote 1394 buses (if necessary, more than one bus can be linked 
to, for multicast purposes). This implies that, in general, all devices that are 
hosted will have uploadable DCM's. In Figure 1, this is illustrated by the 
shaded boxes attached to each gateway device: in these shaded boxes are 

30 the "proxy" DCM's of selected products located within remote clusters. The 
communication c^HAV^ the radio link can be performed in 

any way, including proprietary methods. AV stream routing (e.g. MPEG) may 
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be done using 'virtual 1394 plugs' which would be co-ordinated with the RF 
addressing to direct the stream to the correct target 1394 cluster. In one 
variant, one or a set of standardised or common DCM's may be already 
present on the bridge. For example, a generic AV/C DCM could be included in 
5 the bridge to control AV/C devices, or a manufacturer could provide built-in 
DCM's for some of their own products. 

An alternative arrangement of interconnected clusters is shown in 
Figure 2. The first cluster 50 comprises a STB 52 linked to a gateway device 
59 by 1394 bus 58. Instead of RF transmission by the gateway 59, the first 
10 cluster includes a personal computer (PC) 54 or similar device which receives 
the MPEG from the gateway 59 as well as the HAVi commands 57 to go to a 
remote cluster. 

The second cluster 60 comprises a digital TVA/CR unit 62 linked to a 
gateway device 69 via 1394 bus 68. As for the first cluster, a PC 64 is 

1 5 connected to the gateway 69 which receives MPEG from the PC 64, as well as 
the HAVi commands 65 from the first cluster 50. In this example, 
communication of MPEG and the HAVi commands is accomplished between 
the PC's 54, 64 via wireless link following IEEE 802.11 WLAN standards with 
each PC including an RF ISA/PCI card. Available cordless data links following 

20 these standards include Diamond HomeFree (which has a data rate of 1Mbps) 
and RadioLan (10Mbps). 

In general, such an arrangement is less favoured than that of Figure 1 
in that a certain amount of buffering is liable to be required at the send and/or 
receive sides, although this can simply be provided by the PC's. The 

25 arrangement does have benefit, however, in that it can accommodate devices 
unsuited for connection to the 1394 bus of a cluster: in Figure 2 this is 
illustrated by analogue TVA/CR 67 adjacent the second cluster which is 
supplied with images from an MPEG decoder 66 fed directly from the PC 64 of 
the cluster. 

30 A further interconnect arrangement is shown in Figure 3 and comprises 

three clusters 70, 80, 90 each having a respective cordless bridge CB device 
as gateway device 71, 81, 91. In this example, the bridging between the 
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clusters is by full cordless communications and at data rates determined by 
the cordless protocols used. 

A problem that can arise with sending streams over 1394 bridges is 
how to handle the 1394-level timestamps present in many of the streaming 
5 formats. These are required because packet delivery is time critical for some 
formats, including MPEG. Buses on 1394 have a bus-wide clock such that, for 
timestamps generated on one bus to be valid on another, the clocks of the two 
buses must somehow be synchronised which, the skilled reader will recognise, 
is not always a simple matter. In addition, timestamps within transmitted data 

10 packets may need modification or adjustment by the bridge to take account of 
generally longer delivery times to devices on the far side of the bridge than to 
devices on the data originating bus. 

In order to avoid such problems, a system as shown in Figure 4 is 
suitably employed, with the 1394 buses 100, 110 on either side of the bridge 

15 120. At point a, packets from the 1394 bus 100 are encoded and timestamped 
as specified in a further standard, IEC61883. 

At point b, all the packets have passed through an interface chip or 
circuit assembly PHY 102 acting as interface to the 1394 physical layer, and 
through a link chip or circuit AVLINK 104 which implements IEC61883 for the 

20 relevant streaming format: an example of this chip is the Philips PDI1394L1 1. 
At b, the packets have had all 1394/61883 timestamps removed. Packets are 
released from the AVLINK chip 104 at the correct times, such that the timing 
information is now embodied by the release times of the packets themselves. 
In the following, we assume a packet is released at time t. 

25 The next step is the sending of the packet across the bridge 120: the 

only requirement of the bridge system is that it delivers the packet with a 
constant delay, referred to herein as T. How the bridge achieves this 
constancy is beyond the scope of the present invention: what matters is that a 
packet can be relied upon to arrive at a further AVLINK chip 114 on the other 

30 side of the bridge at time = t + T. 

At point c, packets arrive at the "correct" time due to the constant delay 
T, and the AVLINK chip will now encode and timestamp them in conventional 
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fashion, as dictated by IEC61883. These timestamps will be in the context of 
the second bus 110. If it is determined that packets have been lost or 
corrupted by the bridge 120, it is here at c, between the bridge and AVLINK 
114 that recovery actions should be initiated. 

5 From point d, having been passed through a further physical layer PHY 

interface 112, the packets are sent out over the second bus 110 with 
timestamps appropriate for that bus. 

To send digital video (DV) streams, there are some different 
requirements, largely due to the fact that DV is slightly less time-critical on 

10 delivery than MPEG, and a slightly different mechanism is used, based around 
the SYT timestamp as also specified in IEC61883. This allows for a stream to 
be sent with an "attached" clock signal, which can be up to 8kHz. To send 
this, a clock signal with a frequency £ 8kHz is input to the AVLINK chip on the 
transmitting node. Every clock cycle (every "tick"), the value of the bus clock 

15 at that instant will be sampled, a constant value will be added to compensate 
for the transport delay, and transmitted over the bridge as part of the stream. 
The receiving node will store the value until such time as its own clock is equal 
to that value, and then output a tick. The 8kHz limit is imposed as only one 
SYT timestamp can be sent per 1394 isochronous packet, of which there are 

20 8000 per second. 

As before, the physical means of transportation for this clock signal 
across the bridge will depend on the construction of the bridge itself. The 
same principle of taking the output from the receiving AVLINK chip on the first 
bus will mean that no timestamps in the context of the first bus appear on the 

25 second bus; the clock signal is just sent over the bridge to be re-timestamped 
to the context of the second bus. 

In the interconnect arrangements described, a number of improvements 
are provided, the first of which may be described as the provision of mobile 
DCM's - that is to say DCM's crossing from one cluster to another. HAVi 

30 describes the Device Control Module (DCM) software which represents (or is 
an abstraction of) the control system of a physical device. This software can 
be run on another device that is capable of running such software. For 
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instance, the DCM for a D-VHS recorder can be run on a Set Top Box. 
Currently, HAVi assumes that all devices in the network are connected on one 
single bus. The present invention extends this by providing for the DCM's to 
cross over the bridge. By having a representation of the remote device on the 
5 near side of the bridge, bridging problems can be greatly simplified as the 
remote device is apparently now on the near side of the bridge. In other 
words, there is provided software on one side of a bridge between buses 
which represents a device on another bus which is connected to another 
portal of the bridge. 

10 A further improvement relates to the usage of so-called Legacy devices 

within the HAVi V1.0 specification. Legacy AV devices (LAV's) are already 
defined in HAVi and allow non-HAVi devices to be accessed and controlled by 
a HAVi network, by the use of DCM's (mentioned above). In effect, the DCM 
for a Legacy device is a bridge between a HAVi network and the native control 

15 of the Legacy Device (e.g. the above-mentioned D2B protocols). In this way, 
non-HAVi devices can be made to appear like a HAVi device on the HAVi 
network. This idea extends this mechanism to allow control of real HAVi 
devices on the far side of a bridge via the representation of that device on the 
near side of the bridge. 

20 A still further improvement relates to the modification of Virtual plug 

parameters. HAVi already describes the capabilities of a connection by 
assigning parameters to "virtual plugs" situated at each end of the connection 
path. In a bridge, parameters such as bandwidth are limited and are less than 
the capabilities of the actual physical device. The modification allows the 

25 representation of a remote device on the near side of the bridge to be 
modified to make allowances for the limitations of the bridge transport medium 
(e.g. RF). 

From reading the present disclosure, other modifications and variations 
will be apparent to persons skilled in the art, including equivalents and 
30 features which are already known in the field of bus-connected and cordless 
communication systems and components and which may be used instead of 
or in addition to features already disclosed herein. 
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CLAIMS 

1 . A local communication system comprising: 

5 a first cluster of devices interconnected for the communication of 

messages via a first data bus and in accordance with a first set of 
communication protocols; 

a second cluster of devices interconnected for the communication of 
messages via a second data bus and in accordance with said first set of 
1 o communication protocols; and 

a data channel linking a device of said first cluster and a device of said 
second cluster, said data channel supporting communication of messages in 
accordance with a second set of communications protocols; 

wherein a device of the first cluster holds a stored software 
1 5 representation of operational features of a selected device of the second cluster 
and any device of the first cluster wishing to interact with said selected device 
instead interacts with said stored representation. 

2. A system as claimed in Claim 1, wherein said stored 
20 representation is generated by said selected device and transmitted via said 

data channel to said device of the first cluster. 

3. A system as claimed in Claim 1, wherein said stored 
representation is modified in response to limitations of said data channel. 

25 

4. A system as claimed in Claim 2, wherein said stored 
representation is modified, on receipt by said device of the first cluster, in 
response to limitations of said data channel. 

30 5. A system as claimed in Claim 1, wherein said stored 

representation models said selected device as if it were a device of the first 
cluster. 
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6. A system as claimed in Claim 1 , wherein the said device of the 
first cluster holding the stored representation is that device of the first cluster to 
which the data channel is connected. 

7. A system as claimed in Claim 1 , wherein said data channel is a 
wireless link. 

8. A communications device having the technical features of a 
cluster-connected device in a system as claimed in Claim 1 . 
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ABSTRACT 

CLUSTERED NETWORKED DEVICES 

5 A local communication system comprises a first cluster (10) of devices 

interconnected for the communication of messages via a first data bus (18) and 
in accordance with a first set of communication protocols, a second cluster (20) 
interconnected via a second data bus (28) and following the first set of 
communication protocols; and a data channel (41) linking a device (19) of the 

10 first cluster (10) and a device (29) of the second cluster (20). The data channel 
(41) suitably comprises an RF link supporting communication of messages in 
accordance with a second set of communications protocols. A device (19) of the 
first cluster (10) holds a stored software representation of operational features of 
a selected device (DVHS-2) of the second cluster (20) and any device (11) of 

15 the first cluster wishing to interact with said selected device (DVHS-2; 22) 
instead interacts with said stored representation. 



(Figure 1) 



